A number of problems exist in smartcards that are to be updated after they have been issued to the customer. In such smartcards, the computing time, communication bandwidth, and transient memory (RAM) are limited. In addition, writing to persistent memory is much more expensive than writing to temporary memory, and finally no assumptions about the integrity of the communications infrastructure can be made.
One problem that exists is the overall time required to load code and linkage information into the smartcard, perform cryptographic decryption and integrity checks over the loaded data, and finally relocate the newly loaded code to prepare it for execution. Another problem that exists, is the amount of temporary data required to perform the above operations, and a further problem that exists, is that systems with state information residing in a persistent memory such as EEPROM are required to ensure that this information stays consistent even in case of unexpected power losses and other failures.
A transition from one consistent system state to another may involve updates of several cells of persistent memory. These updates should be performed atomically, where either all memory cells are updated or none of them. The atomicity of several memory updates is supported by the so called "transaction model" in which the system can designate the beginning of an atomic set of updates by issuing the begin-of-transaction command. This command may be given explicitly or implicitly, i.e. be contained in the atomic set command itself. For instance primitive commands, like the data types "byte" and "short" have to be atomically updated and their mere appearance may serve as begin-of-transaction command. Each persistent memory cell is then updated only conditionally by a transaction support system. That means that a memory cell appears to be updated and reading that memory cell returns its latest conditional value, but the update is not yet committed, i.e. guaranteed to remain in a subsequent start of the system. To commit all performed updates, the transaction-commit command is used. When this operation returns, all updates are guaranteed to be written to the persistent memory. If power is lost or some other system failure occurs prior to the completion of the transaction-commit operation, all conditional updates are discarded.
The implementation of the transaction model is generally based on maintaining a transaction buffer, part of which is in the persistent memory. There are two different modes of operation of the transaction support system. One mode is to maintain in the transaction buffer information allowing restoration of the original state of the memory cells updated in a transaction. Before updating a memory cell in a transaction, the transaction support system stores, in the transaction buffer, the cell's address and the previous value of that cell. This information allows to roll-back to that previous value in case of failure. If power is lost during a transaction, the data stored in the transaction buffer is used to recreate the old system state when power supply is established again.
An alternative approach is to write to the transaction buffer the conditional values of updated memory cells and their address/location instead of the old values. The memory cells themselves keep their old values. When a value is read, the transaction support system first inspects the transaction buffer; if a conditional value of the selected memory cell is in the transaction buffer, this value is returned. If this technique is used, no action is required in case of failure since the persistent system memory is unchanged before the transaction commits. The transaction-commit operation writes the values stored in the transaction buffer to their destinations.
In a resource-constrained environment, such as a smartcard, the size of the transaction buffer is highly critical. The goal of the transaction support system is to make most effective use of the transaction buffer to allow a higher number of updates to be executed within one transaction. Writing persistent memory is time-consuming compared to reading. The other goal is to reduce the number of expensive write-operations to persistent storage needed for transaction support.
Therefore, it is an object of the invention to provide a method and a device for transactional writing of data into a data space in persistent memory using a persistent intermediate buffer with a minimum number of write-operations.
It is another object of the invention to have the consistency of transactional writing guaranteed using a small persistent intermediate buffer (also called a transaction buffer).